One of today's most pressing challenges for enterprises is the integration of their existing heterogeneous information technology (IT) landscapes. For example, a typical enterprise may comprise a wide array of individual modules or software applications, supporting different functions and business units, written in different programming languages, and running on different operating systems. The integration of these modules to the point where information may be readily shared has proved to be a daunting task. However, a fairly recent solution to this problem has emerged in the form of a Service Oriented Architecture (SOA). SOA refers to a software architectural framework that encourages the creation of loosely coupled services that communicate and pass information between the modules. An implementation example of an SOA is the Enterprise Service Architecture (ESA) developed by SAP AG of Walldorf, Germany. In particular, the ESA is implemented through NetWeaver, an integration and application platform, also developed by SAP AG. Other examples of SOA enabling platforms are NET developed by Microsoft and WebSphere developed by IBM.
Specific examples of the loosely coupled services used within an SOA are services. A service, such as a Web service, represents a self-contained, self-describing piece of application functionality that can be found and accessed by other applications. A service is self contained, because the application using the service does not have to depend on anything other than the service itself, and self-describing, because all the information on how to use the service can be obtained from the service itself. The descriptions are centrally stored and accessible through standard mechanisms to all applications that would like to invoke the service.
Because services are generally granular in nature, services may be aggregated into enterprise services, which provide more meaningful building blocks for the task of automating enterprise-scale business scenarios. Enterprise services allow IT organizations to efficiently develop composite applications, defined as applications that compose functionality and information from existing systems to support new business processes or scenarios. Enterprise services may communicate using standard mechanisms, can be described in a central repository, and are created and managed by tools provided by the application platform. The enterprise services repository may be used to store all relevant pre-existing enterprise services and to make them available to selected partners and customers. As used herein, the term “service” shall include both Web services and enterprise services.
The description of the requirements of a service may be accomplished through the use of a service contract. For example, the service contract may be implemented using the Web Services Description Language (WSDL), which enables definitions that describe how to access a service and what operations the service will perform. The service contract may also be implemented using the Enterprise Services Description Language (ESDL), which extends the WSDL by allowing the description of services that interact with business objects. A business object is a contained collection of data, business operations and rules stored within a runtime repository. For example, a business object may be an entire order processing system or a small process within an information system.
The use of service contracts is greatly beneficial in a truly open SOA environment. In such environments, where the user of the service and the service provider are loosely coupled, neither entity (i.e., the service user or the service provider) may know much about the other entity and thus, a service contract may be warranted. For example, neither implementation details of the service nor usage scenarios of the service may be known to the other party. This may occur when an enterprise is using a service developed by a third party service provider or when a business unit within the enterprise is using a service developed by another business unit. A service contract is thus helpful, in that the service contract specifies to any and all users of the service, the functional requirements of the service (e.g., the functionality the service provides and what type of data or business object it will return).
Testing the conformance of services against the functionality described in their service contracts is an important part of a software development process, as it guarantees a certain productivity and quality in software engineering. In almost all business cases, the conformance of the service in relation to its service contract is essential for the service consumers and the service infrastructure. The service provider must guarantee the appropriate support of these service contracts and constraints.
In general, a regular test application, such as the Business Object Browser available in SAP's ESA, may be sufficient for an application developer to test the runtime behavior of a service during implementation. This may be accomplished by navigating through the business object model and executing queries or actions. Unfortunately, the application developer has to do this testing manually. Moreover, such testing only focuses on the construction areas the developer is working on currently, and does not cover the validation of the contract and the constraints the service must fulfill.
Accordingly, there is a need to provide a conformance control module (CCM) for testing the conformance of a service at runtime and design time. The CCM may comprise service contract requirements that must be fulfilled by a service in order that it may be deemed conformant. The service contract requirements are predefined and vary based upon the functionality of the service being called. In addition, in order for a service to be deemed conformant there may be necessary constraints including states, phases, and conditions which are needed for each service call. Further, the service contract requirements may be separated by different interface methods that manage specific semantics, such as data access, transaction control, value sets, actions, etc.
The CCM may also log the complete service sequence, which contains all relevant information of the service to implement a conformance test. This logged information may be subsequently used to reproduce the conformance test. In addition, in the case of a runtime conformance test, it may be necessary for the application developer to be notified of the places of the non-conformance within the service.